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Abstract 


Blockchain is a system where connected nodes work together to perform various 

activities within the system, and all of them maintain their own copy of a system 
Article Info ledger that stores transactions. With the emergence of new blockchain networks 
and the massive growth of users on the network the need for inter blockchain 
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1. Introduction 


Asmoreand moreblockchain networksare being developed and their usecaseis ever on therise, theneed for 
blockchain bridges that links these solitary and private blockchain areon therise. This paper aimsat comparing 
two such bridges, Poly network, abridgealready in useand Inter Blockchain Communication (IBC) anew and 
advance protocol being developed. This paper will list outtheir similarities, their differences and will try and 
makea prediction about thefuture blockchain bridges. 


2. Poly Network 


In order to ensure authenticity of transactions the destination chains verifies the read/ writetransactions on 
thesource chain (Poly Team, 1955). This is done via header synchronization and is thetask of the Poly chain. 
Theentire process can be described in thesteps below: 


¢ Réeayerswill forward read and writeoperation from thesource chain to thedestination chain, i.e, to the 
cross chain management contract on the destination chain. 


¢ Moreover the destination chain must be provided with the operation (write or read) and a proof of 
inclusion of the operation on thesource chain (Poly Team, 1955). 


e Thecross chain management contract will than validatethe proof using Poly chain and if and only if the 
proof is valid will the operation becarried out (Poly Team, 1955). 
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The validation process can be explained as follows: 


¢ Eachnode of Poly chain runs full nodes of all participant chains as a result of which the transactions on 
the participant chains will be availableto Poly chain. Running a full nodeallows Poly chain to perform 
verification of every block (Poly Team, 1955). 


e The Poly chain’s output will contain block headers of each blockchain, and cross chain management 
contract will then be able to use these headers to verify the existence of source chain’s header (in the 
proof) (Poly Team, 1955). 


¢ Soparticipant chain will be ableto perform cross chain validation using the Poly chain. 


¢ Poly chain’s block only stores thehash of the block header of participant chains, and therespective block 
header can be provided when needed as each node of the Poly chain will run full nodes. 


Theverification process used by cross chain management contract can besummed up below: 


Users send cross chain operation to source chain. The operation is mined on thesource chain. Relayers 
pick up thecross chain operation and feeds it to the Poly chain, Poly chain will minenew block that contains 
thehash of the block header of the block mined on thesource chain that contains the operation. Relayer will get 
the operation from the log and will forward the operation as well as proof to the cross chain management 
contractin thedestination chain. The cross chain management contract will use Simple Payment V erification 
(SPV), is alight weight client that is used for verification of blockchain transactions) to get the source chain 
block header from nodesin Poly chain, get hash of block header from block mined in Poly chain, and confirm 
them. In order to prevent tampering with Poly chain’s block and providefurther security from attacks each 
block’s header will storethemerkleroot of themerkletreeformed from combining all merkleroot in the block 
header of Poly chain (Poly Team, 1955). 


3. Inter Blockchain Communication 


IBC isacommunication protocol for heterogeneous ledgers (Christopher, 2020). Unlike Poly network, IBC has 
a different takeon theblockchain bridging solution. Poly network uses what is known asa top down approach, 
i.e, almost any ledgersthat have been designed and developed in their own way can communicate with others 
via Poly Network protocol, whereas IBC uses a bottom up approach wherein only thelegers that have been 
designed from theground up to bel BC compatible can communicate with other such ledgers. IBC has acertain 
requirement for the ledger that must be satisfied in order to usethe protocol. Just likePoly network, IBC also 
relieson relayersto achievecross chain communication and the relayers can read the state of the ledgers and 
submit data to another. IBC protocol defines three abstractions client, connection and channe! in order to 
providerediable, flow controlled and authenticated transfer of data packets between IBC modules on separate 
ledgers (Christopher, 2020). 


3.1. Client 


Defines the property needed for state verification. Analgorithm called validity predicateis used to perform 
verification of state of the other ledger. Light client is aname given to the part of the BC module that uses 
validity predicatefor state verification (Christopher, 2020). 


3.2. Connection 


Connection object contains connection end on each ledger, each associated with a light client on the other 
ledger. Together they enablecross ledger state verification and packer relay through channels. Connections 
are established using ahandshake protocol (Christopher, 2020). 


3.3. Channel 


Channe! abstraction provides message delivery semantics: ordering, exactly once delivery and module 
permissioning. In and ordered channel packets are delivered exactly once in the order they were sent. An 
unordered channel however does not preserve the order of packets upon delivery. All channels provide 
exactly once packet delivery. The packets on oneledger are sent to the modules on other ledger as specified by 
the channel end object (Channd end is an object that holds all necessary information while message passing). 
Channels also contain negotiated encoding and multiplexing options (Christopher, 2020). 
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Poly network uses SPV and full nodes for verification whereas IBC uses light client for the same purpose. 
Theflow of datain IBC can be described in the steps below: 
Connection initiated between ledgers and Channels opened over theconnection. 


IBC module will create the packet and will call the send Packet function. This function will perform 
various checks: 


Check if the channel and connection areopen. 

Check the port. 

Check if packet metadata matches what was agreed to when opening the channel. 
Check if timeout haght has not passed on the destination ledger. 


Increases the sequence number counter (a number assigned to each sending packet to ensurerdiable 
packet delivery). 


Stores a constant sizehash of commitment to the packet data and packet timeout. 


Relayers pick it up asthey arecontinuously monitoring the state of the ledger and they pick up theIBC 
packets that have been committed to theledgers. 


Relayers are responsible for creating the proof of inclusion as well and they do this using information 
such as consensus state, client, connection, channel and packet information. 


The recvPacket function is called by a module in order to receiver and process an IBC packet. This 
function performs various checks: 


Checks the channel and connection are open. 
Checks the calling moduleowns the receiving port. 
Checks the packet metadata matches to what was agreed to when opening the channel. 


Checks thepacket sequence number is the next sequence that the channel end expects to receive (for 
ordered channel, for unordered channel this step is skipped). 


Checks the timeout height has not passed. 
Checks if theinclusion proof matches for the outgoing ledger’s state. 
Sets the acknowledgment value uniqueto thepacket (this steo performed for unordered channd only). 


Increases the packet received sequence number within the channel end object (for ordered channel 
only). 


Oncethepacket is received the acknowledgePacket is called. This function checks that: 
Checks the channel and connection areopen to acknowledge packets. 

Checks the calling module owns the sending port. 

Checks the packet metadata matches the channel and connection information. 

Checks the packet was actually sent on this channel. 


Checks the packet sequence is the next sequence, the channd end expects to acknowledge (for ordered 
channels). 


Checks theinclusion proof of thepacket acknowledgment data in the receiving ledger’s state. 
Deletes the packet commitment (cleaning up state and preventing replay). 
Increments the next acknowledgment sequence (for ordered channel's). 


4. Why Poly and Why IBC? 


4.1. Connection 


Both the protocol upon brief studying depends on a relayer entity for cross chain communication. This 
intersection between the two different protocols suggested that the working of theprotocols at the core was 
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much similar than what is initially perceived. So, even though these protocols have different approaches to 
cross chain communication, ultimately they sharea common similarity in rdayers. And this similarity is what 
madethis comparative study possible. 


4.2.M arket Cap of Poly 


Poly network is an already running and fully developed protocol. M any ledgers have partnered with Poly 
network to enable cross chain transaction and is oneof the most widely used blockchain bridging solution at 
the time of starting this research (2021). Though it has suffered the biggest hack of assets in crypto history the 
hacker has begun the process of returning all the funds and has been hired as thesecurity analyst within the 
organization making the protocol less susceptibleto future hacks. In aword it is battletested. 


4.3. Sound logic of IBC 


IBC is what seems to bethesecond generation bridging solution that builds on top of the foundations laid by 
Poly network. Though at their core they are different oneis a bottom up approach while the other is atop 
bottom approach but thesimilarities cannot be disregarded. 1BC’s sound logic and detailed attention to every 
detail (ordering, timeouts, and better verification process) is why IBC was chosen to be compared with Poly 
network. 


5. Discussion 
This section will describethe findings of this research. 


5.1. Why the Bottom up Approach was Introduced in| BC? 


Let us look at the scenario in Polkadot that justifies the introduction of thebottom up approach. Polkadot uses 
atop down approach. 


¢ Inorder to pass message between para chains achannd is opened between them. 
e Thecollator of sender chain will gossip this to both light and full nodes of relay chain. 
e Thegossiped message will have destination and timestamp among other attributes. 


e¢ When the collator on the receiving para chain gets the message it will perform initial verification and 
send the blocks to validators. (Collators run full node of therelay and para chain so they will have access 
to the gossiped message). 


Thevalidators will validatethe block and compress this block which then gets added to therelay chain. 


In order to achieve this message passing, protocol named XCM P is used, the collators of Polkadot needs 
to run full nodes of therelay chain as well as the pair of para chain (P oly T eam, 1955). The nodespecification 
for running acollator will be extremely high as it needs to run full nodes of both the relay and the pair of 
para chains. Also, the nodes need to be actively listening for events in the para chain and therelay chain. 
And if this sharded system exceeds its threshold for fault tolerance than the message passing will not work. 


Thisis mitigated inIBC dueto the bottom top approach. Dueto theuseof relayersinIBC which does not run 
full nodes rather uses validity predicate algorithm or alight client of the pair of ledgers over achannel in order 
to send cross chain messages. 


5.2. Dependence on theuse of Relayers 


Distributed ledgers are by natureclosed off to the internet and can bethought of as an intranet between the 
peers in thenetwork. Thecurrent state of theledger must bethe same when replaying all the transaction from 
genesis block to thelatest block at any given time. This is the reason why block chains aren’t A PI compatible 
as replaying the samerequest to theA PI at another point in time would yield different response and would 
causea fork intheledger. This is also why ledgers aren’t aware of oneanother meaning Ethereum network is 
unawareof theexistenceof Bitcoin network as they are closed off to oneanother and cannot communicatewith 
each other. So, aliteral middleman is required that can relay messages betw een these two closed off networks. 
Relayer entities were born out of need for such requirement in order to bridgetheseledgers. Dueto thepropety 
of distributed ledgers all future bridging solutions will havearelayer entity. 
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5.3. Additional Features of IBC 


Due to the dependence on relayers the work of bridges are similar. All bridging solution will end up using 
relayers by necessity and so the new bridging solutions will just be upgraded versions of the old ones with 
new features and approaches but the major aspect, i.e, relaying will bethesame. This applies to PolyN etwork 
and IBC wherethe former can be thought of as version 1 and the latter as version 2. Theadditional features 
provided by IBC areas: 


5.3.1. ReiableT ransfer of Packets 


IBC moduleassigns sequence number to each packet being sent. This sequence number is checked by the IBC 
handler on the receiving ledger. The sequence number is contained by the channel end (A channel end isa 
data structure that stores metadata associated with one end of achanne! on oneof theparticipating ledger). 


5.3.2. Ordered Channel 


Ordered channel are channel where the data packets are sent and received in order. Ordered channel used 
sequencenumber for managing the proper order of data packets. 


5.3.3. Reject D ata Packets 


The encoding options agreed to when opening achannel and thenext Expected Sequence number represents 
the next data packet expected. If anyoneif these do no match then the! BC modulecan reject data packets. 


5.3.4. Timeout P ackets 


A packet being sent contains a timeout H eight and a timeout Time Stamp. These attributes of the interface 
packet will allow thedata packet sent to havea lifespan. If thetimeout H eight or timeout Time Stamp exceeds 
what is defined in the packet interface when committing it to the ledger than the packer will not be further 
processed and will be dropped. 


5.3.5. Proof V erification (Validity Predicate) 


IBC defines an algorithm called validity predicatethat is used to verify the state of ledgers. IBC modules that 
implement validity predicate are called light clients. Using light clients, a module on oneledger can easily 
verify the state of another ledger. 


5.4. A dvance Relayer Algorithm of IBC 


Therdayer of IBC has more features than therdayer in Poly network. Sincel BC supports ordered and unordered 
packet delivery so therearedifferent algorithms defined that must be used to get the packets to berelayed as per 
therequirement. 


Theserelayers can extract the packet to be relayed using two methods: 


5.4.1. Event Based 


Therelayer should watch thesourceledger for events emitted whenever packets are sent, then composethe 
packet using thedata in the event log. 


5.4.2. Query Based 


Therelayer should periodically query the send sequence on the source ledger, and keep the last sequence 
number rdayed, so that any sequences in between thetwo are packets that need to be queried and then relayed 


Packets in an unordered channel! can most easily be relayed in an event-based fashion and packets in an 
ordered channd arerelayed using the query based method. 


Subsequently, the relayer should check whether the destination ledger has received the packet already 
by querying for the presence of an acknowledgment at the packet’s sequence number, and if oneis not yet 
present the relayer should relay the packet. Therelayer in IBC relay morethan just data packets. They also 
relay acknowledgment to the sending ledger. Therelayer should watch the destination ledger for events 
emitted whenever packets are received and acknowledgments are written, then compose the 
acknowledgment using the data in the event log, check whether the packet commitment still exists on the 
source ledger (it will be deleted once the acknowledgment is relayed), and if so relay the acknowledgment 
to the source ledger. 
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6. Conclusion 


Thisreview paper compares thetwo blockchain bridging solutions, |BC and Poly M arket. The paper highlights 
thesimilarities between these protocols by explaining the dependenceon rdayer entities for achieving cross 
chain communication as well as the difference of features provided by the protocols and thedifferencein the 
flow of data during across chain communication process. 

This paper was written for the sole purpose of providing knowledge for anyonethat maybe interested in 
how each of these protocols work under the hood and for their similarities and differences. The paper also 
makes a claim that says that all of thefuturebridging solutions will haveto usearelayer entity to achievecross 
chain communication. Only time will tell how this claim holds up but there may be new efficient ways that 
may beengineered in the future. 

In conclusion, the paper clearly shows that IBC protocol is more advance, better planned, secure and 
effective(in theory as theprotocol is still being devedoped at thetimeof writing this paper) than Poly N etwork 
which has had thebigger hack in crypto of $600 mn (which is being returned). All in all these protocols will act 
as the building blocks and have clearly advanced the bridging solutions by morethan what was thought to be 
capablewhen wefirst had the question of how to bridgeledgers. 
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